✅ Engine Compatibility

Note: This flow can be ruesed accross repositories the following way:

uses: UI5/cli/.github/workflows/engine-compat.yml@main
with:
  node-versions: '20, 22, 24'

The caller uses owner/repo/.github/workflows/file.yml@ref syntax instead of ./.github/workflows/...
No copying needed. The @ main can also be a tag (@ v1) or SHA for pinning.

I gave it a try in an external repositorty and it seems to be working correctly:

• https://github.com/d3xter666/test-ci/pull/1/changes#diff-86c810903f8631220438a8f9ec529ccb2ac3f52ca950cc95a999397077deb106R18
• https://github.com/d3xter666/test-ci/actions/runs/24188653031/job/70599746155

This is a good idea, but I'm wondering how we can ignore dev-dependencies as discussed last week?

The check-engine-light implementation seems rather simple. If the lack of usage is really a concern for us we can also consider implementing such a tool ourselves. I had already started doing that, but then found that my name of choice "check-engine-light", was already taken by a tool with the very same functionality. In general, the check is really easy to implement and more efficient than the proposal here since we only need to parse the lockfile and not install any packages.

This is a good idea, but I'm wondering how we can ignore dev-dependencies as discussed last week?

The check-engine-light implementation seems rather simple. If the lack of usage is really a concern for us we can also consider implementing such a tool ourselves. I had already started doing that, but then found that my name of choice "check-engine-light", was already taken by a tool with the very same functionality. In general, the check is really easy to implement and more efficient than the proposal here since we only need to parse the lockfile and not install any packages.

If it's for the control of dependencies, we can leverage the --omit or --include flag.
Something that we also need to consider is how to redistribute this check accross all the repositories we own.
With this approach we easily update/modify the script in a single place and it automatically appears on the other repoisories. It can be "forzen" for certain repositories by providing a specific tag/hash/branch. Also this solution uses native and built-in tools that will always work. Direct access to PRs via gh CLI.

The issue with the listed packages are actually what we currently have- potential lack of update in case of security issues, not a major version (the major version release might not fit our engine).

From that perspective, if we want to use a custom script, we have the following options:

• Parse package-lock.json / npm-shrinkwrap.json (how to identify not prod dependencies?)
• Use shell with npm ls --json [--omit <dev|optional|peer>] command, so we can leverage Node's parsing directly without manually parsing anything or including dependencies like arborist, for example

Then we'll simply use semver in order to compare packages' versions against our package.json
Then, we have the following chalenges to address:

• What we want to do with this information?
  • Post to GitHub (maybe directly invoke gh in shell)
  • Exit code?
  • Something else
• How to redistribute the script?

This is a good idea, but I'm wondering how we can ignore dev-dependencies as discussed last week?
The check-engine-light implementation seems rather simple. If the lack of usage is really a concern for us we can also consider implementing such a tool ourselves. I had already started doing that, but then found that my name of choice "check-engine-light", was already taken by a tool with the very same functionality. In general, the check is really easy to implement and more efficient than the proposal here since we only need to parse the lockfile and not install any packages.

If it's for the control of dependencies, we can leverage the --omit or --include flag. Something that we also need to consider is how to redistribute this check accross all the repositories we own. With this approach we easily update/modify the script in a single place and it automatically appears on the other repoisories. It can be "forzen" for certain repositories by providing a specific tag/hash/branch. Also this solution uses native and built-in tools that will always work. Direct access to PRs via gh CLI.

The issue with the listed packages are actually what we currently have- potential lack of update in case of security issues, not a major version (the major version release might not fit our engine).

From that perspective, if we want to use a custom script, we have the following options:

• Parse package-lock.json / npm-shrinkwrap.json (how to identify not prod dependencies?)
• Use shell with npm ls --json [--omit <dev|optional|peer>] command, so we can leverage Node's parsing directly without manually parsing anything or including dependencies like arborist, for example

Then we'll simply use semver in order to compare packages' versions against our package.json Then, we have the following chalenges to address:

• What we want to do with this information?

  • Post to GitHub (maybe directly invoke gh in shell)
  • Exit code?
  • Something else

• How to redistribute the script?

Just created a separate version with check-engine-light: #1360
Of course, we can quite simplify it and just reuse the check-engine-light package. I remember though that we discussed we just want the information whether certain package is ok or not. With the current setup we have the information available, but it's not blocking the PR from being merged.
If we use the pure check-engine-light package if everyhting is ok, then it will complete silently, but if there's an incompatibility it will exit with 1 and this will fail the general ci checks. This will have (almost) the same effect and hit the same boundaries as it is currently with npm ci --engine-strict